11章 設計を進化させる
事業活動の変
企業が成長し進化していくにつれ、ある業務領域のカテゴリーが別にカテゴリーに変化することはよくある。その変化の具体例をまとめる
中核から一般へ
競合他社が自社の競合優位性を損なうような仕組みを開発し、世に浸透した場合
一般から中核へ
パッケージ利用していた在庫管理システムを、自社のニーズに答えれれるよう自社開発に切り替えた場合
補完から一般へ
単純なCRUD操作の契約管理システムを開発して利用していたが、OCRや全文検索など必要になったためOSSの契約管理システムを利用するよう切り替えた場合
補完から中核へ
補完的なロジックを最適化することで、コストの削減や新たな収益を生み出す方法を見つけた場合
中核から補完へ
競合優位性を生み出していた中核の業務ロジックの複雑さが事業収益に貢献していない場合
一般から補完へ
OSSの契約管理システムを利用していたが、自社システムとの連携が複雑になるため、自社開発に戻した場合
設計の基本方針を再検討する
業務ロジックの実装方法を見直す
業務領域のカテゴリーが変化したことを検知する主な指標は、既存の設計では目の前の事業ニーズにうまく対応できなくなったとき 設計の変更
トランザクションスクリプトからアクティブレコードへ
両者の違いはデータ構造の扱い方。アクティブレコードはデータ構造を永続化する仕組みをカプセル化している
トランザクションスクリプトで扱うデータ構造が複雑化してきた場合は、アクティブレコードを使うようにする
アクティブレコードからドメインモデルへ
アクティブレコードを操作する業務ロジックが複雑になり、データ不整合やロジックの重複が増えてきたら、業務ロジックの実装をドメインモデルにリファクタリングする データ構造を分析し、業務ロジックがあり不変として扱いたいデータを値オブジェクトとして記述する
ドメインモデルからイベント履歴式ドメインモデルへ
業務領域に応じて必要であればドメインモデルをイベント履歴式ドメインモデルへ変更する
集約のデータを直接変更する代わりに、集約のライフサイクルを表現する、一連の業務イベントを特定する